3.1 Developing Composite Applications: Unit Testing

Notes/Domino 8 Forum

Subject:

Developing Components: Unit Testing
Jo Grant, Craig Wolpert

Prerequisites:
Review Chapter 1 from Composite Applications Toolkit User’s Guide.
Review the Composite Applications Tutorial

Introduction
Composite applications are a key element in a service-oriented architecture (SOA) and contextual collaboration strategy. They support business flexibility for companies and organizations who wish to rapidly respond to changing demands in today's competitive markets. Composite applications are aggregations of user interface components that are loosely coupled to support inter-component communication. Components can be reused in multiple composite applications. The ability to combine multiple technologies into a single application provides significant business value. It enables companies to protect and extend their existing assets with increasing degrees of flexibility, and to respond quickly and cost effectively to their emerging business requirements, with applications that are significantly easier to create than multiple application development environments.

This loose coupling of the Composite Application Architecture also enables diverse groups in different locations to leverage each others efforts and to interoperate with each other. For example, one department may be working on the accounting application for a company while another group is working on a Sales Lead Tracking Application. The Composite Application vision is that it would be possible to add into the accounting application some components from the sales lead tracking application to give pertinent views of assets in an accounting context. Similarly the sales lead tracking application could incorporate components from the accounting application to give accounting information within an asset context. As your company develops more and more composite applications, the potential for integration increases exponentially. The goal is that the whole is greater than the sum of the parts.

The composition application model is already familiar to IBM(R) WebSphere(R) Portal developers. This approach has been extended to Notes version 8, enabling Notes developers to surface their Notes applications as one or more components in a composite application. IBM(R) Lotus(R) Domino Designer(R) has been extended to leverage the property broker, as well as to provide a more intuitive user environment. Notes version 8 also supports the inclusion of Eclipse components and a composite application may have any combination of Notes components and Eclipse components. These may be just be presented together in the same UI for on the glass integration or if extended to use the Property Broker will fully be able to interoperate with each other. You can define composite applications using the Composite Application Editor or the WebSphere Portal Application Template Editor.

The development of Components for Composite Applications is rather different from traditional Eclipse or Notes application development. It is highly desired to create components that are sufficiently flexible that they can be simply deployed in applications at later dates without significant rework. In order for this to happen components must work well, anticipate new uses, and degrade gracefully for conditions they do not support. This article discusses testing approaches that can be instrumental in creating robust and reliable components.

Unit Testing
The creation of composite applications differs from traditional application development in one important way: the development effort takes place in two stages. First components are written and later those components are assembled into applications. This has several advantages. Since components can be reused in multiple ways, you optimize your effort with a "build once - use many" approach. Secondly, the task of assembling components is not as technical as building components so that a wider mix of people can be involved in the process. That brings application development closer to the end user and results in application designs that build more upon domain expert knowledge.
But with these advantages you also have concerns that need to be addressed. Because components are not custom built for specific uses, you have to try to anticipate all scenarios. Since composite applications are being assembled down the line by less technical people, components have to behave consistently and predictably. Components should also have good documentation describing what are valid values to pass to their interfaces.
One essential approach to ensure the successful development and deployment of components is unit testing. If the components are guaranteed to work well before they are deployed, there will be fewer problems and less frustration in the field when they are put together. That gives a better and more cost effective experience for all.

General Approach
Since components don't interoperate at a code level, traditional methods of unit testing are not necessarily appropriate. Certainly, if the components simply surface lower level business logic, that business logic is best unit tested programmatically. LotusScript libraries can do this for Notes code and the JUnit module for Eclipse is very good for Java code. But for the components themselves, the best way to test them is within the environment they are being build for: a composite application.
The key approach in this article revolves around creating and using a "Tester Component". Quite simply this is a component that has properties and actions of each data type used anywhere in any of your component development. These properties and actions are paired and connected with UI. When an action is set on the tester component, a corresponding part of the UI is filled with the value it receives. This value can be changed or edited by the operator, and a "Set" button pressed. When done this fires off a property with the current value in the edit field.
This test component is then deployed in a composite application with one, and only one, other component; the component under test. Every property that the component under test publishes is wired to an action on the tester component corresponding to the type of that property. Every action that the component under test consumes has a property on the test component of the corresponding type wired to it. In this way every time that any property on the component under test changes value it can be immediately seen by the operator. The operator can also exercise any action in the component under test by filling in a value in the tester component and clicking it's "Set" button.
A test script can now be written and run with this test application to exercise the component under test. The script will contain instructions on what actions to perform in the component under test, and what results are expected to be seen in the test component to track properties being fired. It will also contain instructions on appropriate values to fill in for actions and what the expected reaction is in the UI. This way all of the functionality of the component can be exercised, valid behavior asserted, boundary conditions explored, and graceful degrading ensured.
In some cases it might be preferred to test multiple components in a unit test composite application. In this case, each component should be tested in isolation first before combining components to perform integration testing of components.

Developing the Test Component
The test component may be implemented in either Eclipse or in Notes. Since it communicates on the property broker level, it does not matter which. Pick whichever architecture you are most familiar with. We will discuss both here.
The first step is common to both components. You need to create a WSDL file declaring the properties and actions that your test component uses. First survey the other components that you make use of. Collect from them the namespaces and data type that are used by them. Plan for having at least one property and one action for each unique type. If you have many properties of a single type, or envisage a test case where you might want to distinguish between multiple actions or properties of a single type, just create multiple entries for that in your test component.
If we examine the properties and actions declared by the standard Notes components, we find the following types:

Namespace: http://com.ibm.propertybroker.standardtypes
Types:

emailAddress
canonicalName
commonName
NotesURL
MailTo
toField

Namespace: http://w3.ibm.com/xmlns/ibmww/sw/datatype
Types:

secondaryDateList

Namespace: http://www.w3.org/2001/XMLSchema
Types:

string

(There are also some types based on the datetime format. But we are only covering simple string types in this article.)
So, based on this, we're going to create a single property and action for each of the custom types, and three properties and actions for the generic string type called Misc1, Misc2, and Misc3. To distinguish between the properties and action all property names are prefixed with "get" and all action names with "set". So for this we have the property getEmailAddress, the action setEmailAddress, and so forth.
You can create the WSDL file using the Property Broker Editor that comes with Notes, the WSDL Editor that comes with Eclipse or Radional, or by hand. One approach is to start with a WSDL file from one of your components and then extend this until it has all the required types, and then replace the properties and actions with the new ones.
The WSDL file we will use for this example, based on the above is in Listing 1 at the end of this document

Developing a Lotus Notes Test Component
To create a testing component implemented in Notes it is easiest to create a Notes Component (database) that contains a single Notes Component View. We created a STTester.nsf file based on a blank template. For simplicity of access, we imported our common property broker routines into a LotusScript library. (These routines are discussed in the article "Developing Composite Applications: Notes Components".) Then we added a single form which we called "ST Tester".
In the main area of the form we created a table with one row for each property and action pair we defined, one column for a label, another for an edit field, and a last one for a "Set" button. The fields were named after the base property/action they corresponded to. So for this we have "EmailAddress", etc.
We are going to instrument each "Set" button to publish the value of its corresponding field to the property broker. Here is a simple script to do this:

Sub Click(Source As Button)
Const PropName = "EmailAddress"
Dim workspace As New NotesUIWorkspace
Dim uidoc As NotesUIDocument
Dim PropValue As String
Set uidoc = workspace.CurrentDocument
PropValue = uidoc.FieldGetText( PropName )
publishProperty "get"+PropName, PropValue
End Sub

Since we're going to be cutting and pasting this script into each Set button, and the only difference between them is the property name, we declare this in a constant at the top of the script. After pasting we just need to make a single change in that one place. The rest of the script is very straightforward. We get the current value from the field in the document. And then we publish it to the property broker.
For each value, as well, we are going to define a notes action. In the Infobox for the notes action we map it to the corresponding property broker action defined in the WSDL. The body of the action is a similarly simple script:

Sub Click(Source As Button)
Const PropName = "EmailAddress"
Dim workspace As New NotesUIWorkspace
Dim uidoc As NotesUIDocument
Dim PropValue As String
Set uidoc = workspace.CurrentDocument
PropValue = getActionParameter()
uidoc.FieldSetText PropName, PropValue
End Sub

The only difference here is that we are getting the passed in value from the property broker action, and assigning it to the field it corresponds to.
Lastly, as described in the Composite Applications Tutorial, it is recommended that you create an invisible SaveOptions computed text field with a value of "0". This prevents the system prompting you to save the form when it is closed.
When complete you can add this component to your palette and then to a composite application. It is recommended that you create a unit test for your unit test component! This may seem a little redundant, but unit testing applies just as much to the tools you are testing with as to what you are testing.

Developing an Eclipse Test Component
The development of an Eclipse Test Component follows along the lines described for any Eclipse based Component in the article "Developing Composite Applications: Expeditor Components". A plugin is created to house the component, the WSDL file added, and the basic classes of the View, the data model, and the action handler created and referenced in extension points.
In the data model create a field for each property/action pair. Expose these through set and get accessor functions. Make sure that the set functions publish their changes to the property change support mechanism. This is how the helper libraries know when to publish a property.
The View is created a bit differently from the standard approach detailed in the "Expeditor Components" article. Normally for paired properties and actions you want information to be chained. When an action is set, the corresponding property is called. That allows a lot of flexibility in the way a component is wired. However, in this case, we want to very deliberately separate how a component receives and sends properties. Otherwise we can't be sure of propagation. And being able to know exactly what happens is essential for testing.
So, instead of creating a single data model for the view, we are going to create two. One is tied to incoming actions, and the other is tied to outgoing properties. We will attach a listener to the incoming data model. When it is notified of a change it reads the value from the incoming data model and writes it into the UI field. For the other direction, we attach a listener to the "Set" button. When pressed it reads the current value of the UI field, and writes it into the output data model. This is linked via the libraries to broadcast out property changes.
For the whole file, please see the attached project. Below are some excerpts showing where things are a bit different from the standard model.
Firstly we declare two data models instead of one:

private STTesterViewBean mDataIn;
private STTesterViewBean mDataOut;

public STTesterView() {
mDataIn = new STTesterViewBean();
mDataOut = new STTesterViewBean();
}

The output model is registered with a PBBroadcast() helper object. This ensures that changes to it are broadcast as property changes:

new PBBroadcast(this, mDataOut, "http://com.ibm.propertybroker.standardtypes,http://w3.ibm.com/xmlns/ibmww/sw/datatype,http://www.w3.org/2001/XMLSchema");

The input model is references in the getData() method required by the abstract IDataProvider interface in the helper library. This ensures that actions received are written to the input data model.

public PCSBean getData() {
return mDataIn;
}

A helper function is created to add each line to the display:

addLine(client, "EmailAddress");
...

private void addLine(Composite client, String name) {
GridUtils.makeLabel(client, makeLabelName(name), "");
Text input = GridUtils.makeText(client, (String)null, "fill=h");
mDataIn.addPropertyChangeListener(makePropertyName(name), new DoInput(input));
Button go = GridUtils.makeButton(client, "Set", "");
go.addSelectionListener(new DoOutput(input, name));
}

This helper function creates the label, the input field, and the "Set" button for each property/action pairs. It creates the needed listener to listen to the input data model, and to propogate changes from it to the UI field. And it creates another listener to listen to the "Set" button, and when clicked to publish the value of the UI field to the output data model.

class DoInput implements PropertyChangeListener {
...
public void propertyChange(PropertyChangeEvent ev) {
mControl.setText(ev.getNewValue().toString());
}
}

class DoOutput implements SelectionListener {
...
public void widgetSelected(SelectionEvent ev) {
String newVal = mControl.getText();
PBHandler.setValue(mDataOut, "set"+mProperty, newVal);
}
}

The same as with the Notes implementation, when complete you can add this component to your palette and then create a unit test for it.

Creating a Unit Test Plan
Every component should have a specification detailing what properties it publishes under what conditions, and what actions it consumes, what are valid values for those actions, and what it does when it consumes such an action. This is discussed in the "Designing Composite Applications: Component Design" article. "Designing Composite Applications: Managing the Process" also discusses good specification techniques. A good test plan will cover and validate each of those areas. If there is a good specification, it is easy to write a good test plan.
This tester component can be instrumental in validating the test plan. Although typically, a component will be deployed with an array of other components and linked up to propagate business logic. However this does not make a good test environment. You cannot create specific circumstances and since you are testing more than one thing at a time confusion can arise over what part is failing. What is recommended is that you create a very simple composite application with just the component under test in it and the tester component. Wire each property in the component under test to a valid action in the test component. And for each valid action in the component under test, ensure that a wire is created to it from the tester component. Once each component is unit tested, it will be easier to assemble and wire the components in the application. Test components are never done, they should be updated as components change,
For Notes component views it should be noted that properties and actions are scoped to the component (database) not the component view (form/frameset/view). So properties and actions may appear where they are not valid values for that component. The specification for the component view should delineate which of those properties and actions are valid for that component. However since an end user might wire up the wrong things you should consider adding tests for invalid properties and actions to be added to ensure it degrades gracefully and no unexpected side effects emerge.
Your test plan then becomes a walkthrough. We can even make a checklist:

Positive Testing
UI Gestures. For each UI gesture defined in the specification, create a line in your unit test. Ask the operator to make this gesture. Then check the result of it in the tester component. Did the expected properties publish?
Action Handling. For each supported action, ask the operator to fill in values in the tester and then hit "Set". Did the UI change as expected? If this was also designed to trigger further property firings, did that happen?
Negative Testing.
UI Gestures. Consider all of the other sorts of things a user might do with the UI. Clicking the wrong points, entering invalid values, accented or unusual characters. Create a line for each. Ask the operator to make the gesture and see if properties fire that should not.
Action Handling. For each supported action, come up with all the wrong ways to fill it in. Blank, very large strings, ill formatted data, or accented or unusual characters. Create a line for each with sample text to be cut and pasted into the UI. The "Set" button can be clicked and the component examined to see if it behaves acceptably.
[Action Handling. For each unsupported action, come up with a reasonable variety of values to fill in and set. Ensure that the component ignores them.]

Note: although one can create these test composite apps and use them for your test cycle, it isn't a bad thing to have them created on the fly during your development. They don't take much time to make and they may smoke out problem with deployment and distribution that would otherwise be hard to find later.

Worked Example
Here's an example of a test plan that you might write for testing the Notes Contact View.

Steps	Notes
1. Test Setup
Create an new composite application TestNotesContactView.nsf
In CAE add the NotesContactView on the left and a Standard Types Tester on the right
Open the wiring tool on the NotesContactView component
Wire: Selected Notes Document -> Notes url Canonical Name -> Canonical Name Common Name -> Common Name Email address -> Email address Street address -> Misc 1
Save and open the wiring tool on the Standard Types Tester component
Ensure there are no actions displayed on the NotesContactView component
Exit CAE
Open names.nsf and ensure the correct data set is loaded. Close it.
2. Test Execution
Open the TestNotesContactView application
Ensure that no properties fire Ensure that last selected letter page is shown
Select letter "B" from the left navigator
Ensure that B-last names show Ensure that the first one, Julia Bury is selected Ensure in the tester Email Address is "JuliaBury@HinesContracting.com" Ensure in the tester Canonical Name is "JuliaBury@HinesContracting.com" Ensure in the tester Common Name is "Bury, Julia" Ensure in the tester Misc 1 is "1540 Butte House RdYuba City, CA 95993USA"
Select letter "X" from the left navigator
Ensure that no names show Ensure that no properties change
...

And here is the test component you might use it with:

Beyond Unit Testing
This structure and system has uses beyond simple component validation. No testing is perfect and complicated situations can occur in the field that were not anticipated. These surface as problems for support. The typical developer's nightmare is a problem in a simple component occurring in a complicated application. With a system like this an approach can be taken that examines the log files and other debugging options to try to recreate the inputs to the component that caused the fault. These values can be fed back into the component at fault via the unit test application. With luck the fault can be recreated in the unit test and diagnosed without having to load up the full complicated environment. Of course, once recreated, the instructions for doing so would make an excellent addition to the unit test script so that regressions can be caught in future releases.

Conclusion
This article has provided a solid foundation for developing unit tests and how they provide benefit to composite applications by allowing each component to be tested. The authors of this article have been developing and executing unit testing during the the development of the Lead Manager composite application sample. We believe it is a useful addition to the process which makes it easier to realize the benefit of reusable components in composite application.

Listing 1
<?xml version="1.0" encoding="UTF-8"?>













<definitions name="PropertyBrokerWSDL"
targetNamespace="http://www.ibm.com/wps/c2a/testwsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:portlet="http://www.ibm.com/wps/c2a"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.ibm.com/wps/c2a/testwsdl"
xmlns:ibmcsi="com.ibm.rcp.csiviews"
xmlns:ibmst="http://com.ibm.propertybroker.standardtypes"
xmlns:ibmdt="http://w3.ibm.com/xmlns/ibmww/sw/datatype">

<types>
<xsd:schema targetNamespace="http://com.ibm.propertybroker.standardtypes">
<xsd:simpleType name="emailAddress">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="canonicalName">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="commonName">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="NotesURL">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="MailTo">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="toField">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="selectedDate">
<xsd:restriction base="xsd:dateTime"/>
</xsd:simpleType>
</xsd:schema>

<xsd:schema targetNamespace="http://w3.ibm.com/xmlns/ibmww/sw/datatype">
<xsd:simpleType name="secondaryDateList">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:schema>

</types>
<message name="setEmailAddress_Message">
<part name="setEmailAddress_Part" type="ibmst:emailAddress"/>
</message>
<message name="setCanonicalName_Message">
<part name="setCanonicalName_Part" type="ibmst:canonicalName"/>
</message>
<message name="setCommonName_Message">
<part name="setCommonName_Part" type="ibmst:commonName"/>
</message>
<message name="setNotesURL_Message">
<part name="setNotesURL_Part" type="ibmst:NotesURL"/>
</message>
<message name="setMailTo_Message">
<part name="setMailTo_Part" type="ibmst:MailTo"/>
</message>
<message name="setToField_Message">
<part name="setToField_Part" type="ibmst:toField"/>
</message>
<message name="setSelectedDate_Message">
<part name="setSelectedDate_Part" type="ibmst:selectedDate"/>
</message>
<message name="setSecondaryDateList_Message">
<part name="setSecondaryDateList_Part" type="ibmdt:secondaryDateList"/>
</message>
<message name="setMisc1_Message">
<part name="setMisc1_Part" type="xsd:string"/>
</message>
<message name="setMisc2_Message">
<part name="setMisc2_Part" type="xsd:string"/>
</message>
<message name="setMisc3_Message">
<part name="setMisc3_Part" type="xsd:string"/>
</message>

<message name="getEmailAddress_Message">
<part name="getEmailAddress_Part" type="ibmst:emailAddress"/>
</message>
<message name="getCanonicalName_Message">
<part name="getCanonicalName_Part" type="ibmst:canonicalName"/>
</message>
<message name="getCommonName_Message">
<part name="getCommonName_Part" type="ibmst:commonName"/>
</message>
<message name="getNotesURL_Message">
<part name="getNotesURL_Part" type="ibmst:NotesURL"/>
</message>
<message name="getMailTo_Message">
<part name="getMailTo_Part" type="ibmst:MailTo"/>
</message>
<message name="getToField_Message">
<part name="getToField_Part" type="ibmst:toField"/>
</message>
<message name="getSelectedDate_Message">
<part name="getSelectedDate_Part" type="ibmst:selectedDate"/>
</message>
<message name="getSecondaryDateList_Message">
<part name="getSecondaryDateList_Part" type="ibmdt:secondaryDateList"/>
</message>
<message name="getMisc1_Message">
<part name="getMisc1_Part" type="xsd:string"/>
</message>
<message name="getMisc2_Message">
<part name="getMisc2_Part" type="xsd:string"/>
</message>
<message name="getMisc3_Message">
<part name="getMisc3_Part" type="xsd:string"/>
</message>

<portType name="Operations">

<operation name="getEmailAddress_Operation">
<output message="tns:getEmailAddress_Message"/>
</operation>
<operation name="getCanonicalName_Operation">
<output message="tns:getCanonicalName_Message"/>
</operation>
<operation name="getCommonName_Operation">
<output message="tns:getCommonName_Message"/>
</operation>
<operation name="getNotesURL_Operation">
<output message="tns:getNotesURL_Message"/>
</operation>
<operation name="getMailTo_Operation">
<output message="tns:getMailTo_Message"/>
</operation>
<operation name="getToField_Operation">
<output message="tns:getToField_Message"/>
</operation>
<operation name="getSelectedDate_Operation">
<output message="tns:getSelectedDate_Message"/>
</operation>
<operation name="getSecondaryDateList_Operation">
<output message="tns:getSecondaryDateList_Message"/>
</operation>
<operation name="getMisc1_Operation">
<output message="tns:getMisc1_Message"/>
</operation>
<operation name="getMisc2_Operation">
<output message="tns:getMisc2_Message"/>
</operation>
<operation name="getMisc3_Operation">
<output message="tns:getMisc3_Message"/>
</operation>

<operation name="setEmailAddress_Operation">
<input message="tns:setEmailAddress_Message"/>
</operation>
<operation name="setCanonicalName_Operation">
<input message="tns:setCanonicalName_Message"/>
</operation>
<operation name="setCommonName_Operation">
<input message="tns:setCommonName_Message"/>
</operation>
<operation name="setNotesURL_Operation">
<input message="tns:setNotesURL_Message"/>
</operation>
<operation name="setMailTo_Operation">
<input message="tns:setMailTo_Message"/>
</operation>
<operation name="setToField_Operation">
<input message="tns:setToField_Message"/>
</operation>
<operation name="setSelectedDate_Operation">
<input message="tns:setSelectedDate_Message"/>
</operation>
<operation name="setSecondaryDateList_Operation">
<input message="tns:setSecondaryDateList_Message"/>
</operation>
<operation name="setMisc1_Operation">
<input message="tns:setMisc1_Message"/>
</operation>
<operation name="setMisc2_Operation">
<input message="tns:setMisc2_Message"/>
</operation>
<operation name="setMisc3_Operation">
<input message="tns:setMisc3_Message"/>
</operation>
</portType>

<binding name="Binding" type="tns:Operations">
<portlet:binding/>
<operation name="getEmailAddress_Operation">
<portlet:action name="getEmailAddressChanged" caption="Email address" description="Email address of the sender of the selected email" />
<output>
<portlet:param name="getEmailAddress" partname="getEmailAddress_Part" caption="Email address" description="Email address of the sender of the selected email" />
</output>
</operation>
<operation name="getCanonicalName_Operation">
<portlet:action name="getCanonicalNameChanged" caption="Canonical name" description="Canonical name of the selected contact" />
<output>
<portlet:param name="getCanonicalName" partname="getCanonicalName_Part" caption="Canonical name" description="Canonical name of the selected contact" />
</output>
</operation>
<operation name="getCommonName_Operation">
<portlet:action name="getCommonNameChanged" caption="Common name" description="Common name of the sender of the selected email" />
<output>
<portlet:param name="getCommonName" partname="getCommonName_Part" caption="Common name" description="Common name of the sender of the selected email" />
</output>
</operation>
<operation name="getNotesURL_Operation">
<portlet:action name="getNotesURLChanged" caption="Notes url" description="Notes url of the selected email" />
<output>
<portlet:param name="getNotesURL" partname="getNotesURL_Part" caption="Notes url" description="Notes url of the selected email" />
</output>
</operation>
<operation name="getMailTo_Operation">
<portlet:action name="getMailToChanged" caption="New memo using mailto URL" description="Create a new memo using provided mailto URL" />
<output>
<portlet:param name="getMailTo" partname="getMailTo_Part" caption="New memo using mailto URL" description="Create a new memo using provided mailto URL" />
</output>
</operation>
<operation name="getToField_Operation">
<portlet:action name="getToFieldChanged" caption="New memo using to field" description="Create a new memo using provided string" />
<output>
<portlet:param name="getToField" partname="getToField_Part" caption="New memo using to field" description="Create a new memo using provided string" />
</output>
</operation>
<operation name="getSelectedDate_Operation">
<portlet:action name="getSelectedDateChanged" caption="Selected date" description="The selected calendar date" />
<output>
<portlet:param name="getSelectedDate" partname="getSelectedDate_Part" caption="Selected Date" description="The selected calendar date" />
</output>
</operation>
<operation name="getSecondaryDateList_Operation">
<portlet:action name="getSecondaryDateListChanged" caption="Secondary date list" description="Visible but not necessarily selected dates" />
<output>
<portlet:param name="getSecondaryDateList" partname="getSecondaryDateList_Part" caption="Secondary date list" description="Visible but not necessarily selected dates" />
</output>
</operation>
<operation name="getMisc1_Operation">
<portlet:action name="getMisc1" caption="Misc1" description="Misc1"/>
<output>
<portlet:param name="getMisc1" partname="getMisc1_Part" caption="Misc1" description="Misc1"/>
</output>
</operation>
<operation name="getMisc2_Operation">
<portlet:action name="getMisc2" caption="Misc2" description="Misc2"/>
<output>
<portlet:param name="getMisc2" partname="getMisc2_Part" caption="Misc2" description="Misc2"/>
</output>
</operation>
<operation name="getMisc3_Operation">
<portlet:action name="getMisc3" caption="Misc3" description="Misc3"/>
<output>
<portlet:param name="getMisc3" partname="getMisc3_Part" caption="Misc3" description="Misc3"/>
</output>
</operation>

<operation name="setEmailAddress_Operation">
<portlet:action name="setEmailAddress" caption="Email address" description="Email address of the sender of the selected email"/>
<input>
<portlet:param name="setEmailAddress" partname="setEmailAddress_Part" caption="Email address" description="Email address of the sender of the selected email" />
</input>
</operation>
<operation name="setCanonicalName_Operation">
<portlet:action name="setCanonicalName" caption="Canonical name" description="Canonical name of the selected contact"/>
<input>
<portlet:param name="setCanonicalName" partname="setCanonicalName_Part" caption="Canonical name" description="Canonical name of the selected contact" />
</input>
</operation>
<operation name="setCommonName_Operation">
<portlet:action name="setCommonName" caption="Common name" description="Common name of the sender of the selected email"/>
<input>
<portlet:param name="setCommonName" partname="setCommonName_Part" caption="Common name" description="Common name of the sender of the selected email" />
</input>
</operation>
<operation name="setNotesURL_Operation">
<portlet:action name="setNotesURL" caption="Notes url" description="Notes url of the selected email"/>
<input>
<portlet:param name="setNotesURL" partname="setNotesURL_Part" caption="Notes url" description="Notes url of the selected email" />
</input>
</operation>
<operation name="setMailTo_Operation">
<portlet:action name="setMailTo" caption="New memo using mailto URL" description="Create a new memo using provided mailto URL"/>
<input>
<portlet:param name="setMailTo" partname="setMailTo_Part" caption="New memo using mailto URL" description="Create a new memo using provided mailto URL" />
</input>
</operation>
<operation name="setToField_Operation">
<portlet:action name="setToField" caption="New memo using to field" description="Create a new memo using provided string"/>
<input>
<portlet:param name="setToField" partname="setToField_Part" caption="New memo using to field" description="Create a new memo using provided string" />
</input>
</operation>
<operation name="setSelectedDate_Operation">
<portlet:action name="setSelectedDate" caption="Set selected date" description="sets the date that the UI indicates is selected"/>
<input>
<portlet:param name="setSelectedDate" partname="setSelectedDate_Part" caption="date to be set to" description="the date that we should set it to" />
</input>
</operation>
<operation name="setSecondaryDateList_Operation">
<portlet:action name="setSecondaryDateList" caption="Set secondary date list" description="sets the list of secondary dates"/>
<input>
<portlet:param name="setSecondaryDateList" partname="setSecondaryDateList_Part" caption="Secondary date list" description="The new list of secondary dates" />
</input>
</operation>
<operation name="setMisc1_Operation">
<portlet:action name="setMisc1" caption="Misc1" description="Misc1"/>
<input>
<portlet:param name="setMisc1" partname="setMisc1_Part" caption="Misc1" description="Misc1"/>
</input>
</operation>
<operation name="setMisc2_Operation">
<portlet:action name="setMisc2" caption="Misc2" description="Misc2"/>
<input>
<portlet:param name="setMisc2" partname="setMisc2_Part" caption="Misc2" description="Misc2"/>
</input>
</operation>
<operation name="setMisc3_Operation">
<portlet:action name="setMisc3" caption="Misc3" description="Misc3"/>
<input>
<portlet:param name="setMisc3" partname="setMisc3_Part" caption="Misc3" description="Misc3"/>
</input>
</operation>
</binding>
</definitions>

Feedback response number JGRT77URKP created by ~August Umtumitherader on 10/10/2007